Conduct-by-wire - following a New Paradigm for Driving into the Future

This paper presents a new concept for future cars combining potentials of Advanced Driver Assistance Systems (ADAS) and X-by-Wire technology. Based on current developments in technology ADAS will cover a great part of standard traffic situations and offer assistance on the conducting level to the driver. As a result, in addition to basic driving functions on stabilising level assumed as fundamental so far (steering, braking, accelerating), the driver now has to deal with the operation of a greater number of control elements and furthermore the attention to new display elements. Beyond the extension of the Human-Machine-Interface (HMI) interdependencies between assistance and basic driving functions now arise, which are associated with the new requirement for the driver to be aware of which functional mode the vehicle is in. The idea of Conduct-by-Wire is to transfer the vehicle control from stabilising to conducting level. Driver assistance functions and basic operations (steering, braking and accelerating) are an integral part of a vehicle guidance system which communicates with the driver on manoeuvre basis. For this, a large number of developments of operational elements can be mentioned which range from multifunctional elements similar to a steering wheel or a joystick. Indeed, instances of these forms are known from various X-by-Wire concepts. Unlike them, the operational units of Conduct-by-Wire serve as a command interface for manoeuvres and appropriate parameters. A vehicle with such an HMI will transform the various inputs of the conducting function in a motion vector and convert it into motion on the stabilising level without the driver’s help. As a result a mechanical or hydraulical coupling between operational element and wheel actuator becomes useless, so that an underlying X-by-Wire architecture has to be chosen logically. The Conduct-by-Wire concept breaks away from the paradigm of a driver interface on the stabilising level and chooses the conducting level instead. As a result consistent and simplified vehicle guidance is realized, which provides the most of the ADAS-functionality without removing the driving responsibility from the driver. A further advantage of this concept is the simplicity of the vehicle’s architecture with a very simplified command flow with no need of coordination between the functions of the controlling systems, i.e. a motion vector is absolutely sufficient for the control of the underlying X-by-Wire systems. TECHNICAL PAPER – Driver Assistance Systems considerably contribute to facilitate vehicle guidance (1) and improve the total efficiency of the driver/vehicle unit in many situations. However, these systems’ control complexity increases with every rise of the assistance degree. To ensure the safe use of assistance functions in the intended way the driver must possess the necessary functional knowledge. The driver switches between different modes which partly are not explicitly known to users by means of function-specific switches or by primary control elements. As a consequence the transparency of the functions suffers. For a discussion of alternative ways the driving tasks of driver and assistance systems are structured in the following model. MODELING OF THE DRIVING TASKS' PARTITION If one considers driving functions classified in driver, vehicle and environment, as well as in navigation, vehicle guidance and stabilisation levels according to (2) in figure 1, one finds in the traditional vehicle guidance cascading control loops, which are regulated by the controller “driver“ on three levels with three time constants of different dimensions. Modern Driver Assistance Systems inherit independent control functions as well. This causes not only an additional control loop for stabilisation (e.g. with vehicle dynamics control ESP/DSC/VDC/...), but also a loop on vehicle guidance level with functions such as Adaptive Cruise Control and partially one on navigation level for dynamic route tracking as well. The control loops are in general used alternatively. Figure 1: Three-level hierarchy of driving task according to (2) The switching is carried out for stabilisation after the recognition of a critical driving situation, i.e. with exceeding a deviation threshold between the driver specification (e.g. nominal yaw rate) and the vehicle dynamics condition (e.g. actual yaw rate, sideslip angle). In the assistance systems on the vehicle guidance level the switching of the regulation loops is carried out from the manual to the automated function (e.g. Adaptive Cruise Control) and back via the activation and deactivation functions provided by the Human Machine Interface (HMI). Furthermore, this switching from automated to manual vehicle guidance is supported by take-over requests which are emitted particularly in case of an automatically recognized reaching of functional limits. Furthermore, the control elements specified for manual vehicle guidance are used for overriding (e.g. accelerator pedal in ACC) or for switching off an automated function (e.g. brake pedal in ACC). The navigation control loops run independently of each other and are supervised by the driver, since he is embedded serially into the complete loop (also via HMI) for the implementation of the driving mission for the assisted loop as well. Another HMI task of Driver Assistance Systems is parameterisation of the support function e.g. by setting the desired speed or distance program in ACC. If one adds this expansion to the three-level-model known from figure 1, a clear increase of complexity on all levels can be seen (see figure 2). Figure 2: Three-level hierarchy of driving task with added support functions As a price for the comfort and performance profit by Driver Assistance Systems a high mode awareness is required, which is mostly coupled with high situation awareness. The mode changes are often not transparent and usually result from technical restrictions. The transparency loss with an increasing degree of automation reaches up to a level where only few interventions are still performed by the driver, which means that one drives almost autonomously. This plot of transparency vs. automation degree is called the Grand-CanyonDilemma among experts, which means pictorially a wide and deep valley of intransparency which hinders the further development of Driver Assistance functions. However, this consideration relies on a task sharing in the sense of a parallel assistance and a development direction to a completely autonomous vehicle guidance. AUTONOMOUS VEHICLE GUIDANCE Fully automated vehicle guidance or autonomous vehicle guidance, respectively, considerably simplifies the structure shown in figure 2. The driver’s function confines itself to communicating the driving mission to the vehicle navigation. The remaining processing chain runs analogously to figure 1, with the significant difference, that the processing chain is taken over by the vehicle itself completely, see figure 3. Of course, a switching can be specified between these two extreme approaches of simply manual and autonomous driving. Figure 3: Three-level hierarchy for autonomous driving However, for the implementation of autonomous vehicle guidance there are still considerable obstacles which can be classified into the categories technology, law and user acceptance. Technical obstacles are primarily the still insufficient performance of sensors and that of perception and situation interpretation algorithms. Indeed, in defined environments fully automatically carried out missions were managed successfully as e.g. the DARPA-Grand Challenge (3) in 2005 or the successful autobahn driving from Munich to Odense in 1995 (4); however, current technology is far away from the perception performance level of a human. As an example, night driving in rainy conditions has to be mentioned as a situation for which no roadworthy machine solution is known to the authors. It has to be expected that machine perception will be able to provide the information only in clearly defined situations for decisions with sufficiently few errors within the next decades or longer. In the foreseeable future the 100% availability necessary for an autonomous mission can be reached only on infrastructure specifically developed for this kind of driving. A considerable use can already arise then, particularly an increased traffic performance, reduced risk of traffic jam or less accidents e.g. in tunnels. Alternative application possibilities of fully autonomous vehicles are in highly endangered areas or completely unmanned uses for civil protection or military applications. According to today's legal constraints for road vehicles the driver alone takes fully the responsibility for guiding. This is determined internationally binding in the 1968 Vienna convention on road traffic of 1968. And even in the case of permission for a fully autonomous driving, a solution for the civil law liability is missing for a failure case of the automatic function. From today's point of view a full responsibility of the OEM according to today's laws for product liability hardly seems acceptable. However, the doubts concerning user acceptance turn out to be an obstacle as well. The fully automatic system will only seldom accomplish the action or the manoeuvres just like the driver of a vehicle would have carried it out himself. PARADIGM SERIAL ASSISTANCE A solution between the extremes of manual driving (driving which is carried out completely by the driver) and fully automatic or autonomous vehicle guidance is offered by a horizontal distribution of the functions between driver and assistance system: The decision function and so the responsibility for the guidance are left to the driver, the execution of his intention is applied to the assistance function, see figure 4. Applied to the 3-level model, this approach means that the driver’s stabilisation task becomes obsolete, see figure 5. Thus the interface between driver and vehicle narrows to the level of vehicle guidance which now must provide all of the driver’s guidance requests. The communication happens by means of a so-called manoeuvre interface. Manoeuvres the driver requests are carried out in the Conduct-by-Wire unit within limits determined by driving physics or environment. In order for the manoeuvre interface to permit at least equally efficient vehicle guidance, one should pay attention to an intuitive HMI which permits just as intuitively both request input and feedback of the current driving condition to the driver. In principle, the concept of serial assistance supported here resembles tests of a Driver-in-theLoop assistance as an ACC-like function with an active accelerator pedal (5) or Lane Keeping Supports (LKS) (6), which both require the driver’s involvement. However, these approaches restrict themselves to adding a new functionality, so that the mode awareness is still required. Furthermore, these two approaches bind to unchanged operation elements, whose form and shape have certainly proven themselves in approximately one hundred years, but which were intended to manage high actuating forces. Figure 4: Parallel vs. serial assistance